1. Field of the Invention
The present invention relates to enforcement of policy requirements by a component of a communications infrastructure. More particularly, the present invention relates to automated enforcement of policy requirements in a public key infrastructure component via a policy enforcing module.
2. Background Information
In general, a communications infrastructure component can be any physical or logical entity that plays a role in the operation of that communications infrastructure. For example, in a distributed data processing network such as the Internet, a communications infrastructure component can include such entities as an Internet Service Provider (ISP), a network server, or a network router. In the particular case of a public key infrastructure (PKI), a communications infrastructure component can include a PKI component. A PKI component can perform many different operations including, but not limited to, distributing, managing, revoking, issuing, certifying, or cross-certifying certificates, or any other operations related to certificate management.
The deployment of public key cryptography, especially in a PKI, relies heavily on certificates. A certificate contains the public key of a user (or end entity), along with information that can allow a relying party to evaluate whether or not to trust a user""s digital signature produced using the private key corresponding to that public key. In particular, the certificate contains the digital signature of a Certification Authority (CA).
In a PKI, a CA issues certificates to end entities. In general, the CA is a secure, standards-based, and trusted entity that can provide certificate issuance, token management, and directory management services. A CA""s digital signature on a certificate indicates that the CA has verified the identity of the user whose certificate it has signed, and the CA""s digital signature also binds the identity of the user to the public key appearing in the certificate.
In order to provide trust to all parties in a PKI involved in electronic transactions which use certificates, policies made up of one or more requirements can be established and followed covering all aspects of the operation of the PKI. These policies can, for example, be followed by a CA. In addition, any subordinate entities in the PKI, such as a Registration Authority (RA), may also need to follow those policies. The policies of the PKI are documented as a collection of requirements or policy elements in a document known as a Certificate Policy (CP). The CA and RA can then enforce the particular policy according to those policy elements via their practices and procedures. The practices and procedures employed by the CA and RA in enforcing the CP are documented in a Certification Practice Statement (CPS). A de facto standard for both the CP and CPS has been established and is known as the PKIX Part 4 framework. The framework provides a checklist of policy elements applicable to a PKI component which should be addressed in the CP and CPS. Many of these policy elements relate to the technical aspects of the PKI which can be enforced in various PKI components. Some examples of policy element categories from the PKIX Part 4 framework which are related to technical aspects of the PKI include key pair generation, key sizes, key usage purposes and authentication of individual identity.
The United States Department of Defense (DoD), in its X.509 Certificate Policy (CP), Version 2.0, dated 1999 March, contains many policy elements. For example, section 6.1.5 of the DoD CP titled xe2x80x9cKey Sizesxe2x80x9d contains the following policy element: xe2x80x9cDSS keys issued by a US DOD CMI shall use 160 bit private key (x) and 1024 bit prime modulus (p). Minimum user public keysizes shall be 1024 bits for KEA and RSA.xe2x80x9d Also, section 3.1.9 of the DoD CP titled xe2x80x9cAuthentication of Individual Identityxe2x80x9d contains the following policy element: xe2x80x9cFor CLASS 4, the user must appear personally before a [Certificate Management Authority], and two credentials must be presented. One must be an official picture ID, such as a passport or DOD ID card; the other may be specified by the program which requires the user to have the certificate.xe2x80x9d
In general, a policy identifier can be any data item which unambiguously identifies a particular policy. As defined in the X.509 standard of the International Telecommunication Union (dated June 1997), an X.509 certificate can contain a certificate policies extension as part of the certificate extensions. The certificate policies extension is an example of a policy identifier since it lists the certificate policy object identifiers, each of which identifies a particular CP, which the issuer authorizes and which apply to the certificate. The X.680 standard of the International Telecommunication Union (dated July 1994), provides the standard notation for these certificate policy object identifiers.
In addition to a policy identifier, optional qualifier information can be included which pertains to these certificate policies. According to the X.509 standard, xe2x80x9c[t]ypically, different certificate policies will relate to different applications which may use the certified keyxe2x80x9d and xe2x80x9c[c]ertificate policies and certificate policy qualifier types may be defined by any organization with a needxe2x80x9d.
In the past, RAs did not exist at all, and even when they did, the automated imposition of policy constraints did not occur. Furthermore, no technology currently exists with the ability to automate enforcement of technical aspects of a policy in a PKI.
For example, U.S. Pat. No. 5,164,988 to Matyas describes a xe2x80x9cMethod to Establish and Enforce a Network Cryptographic Security Policy in a Public Key Cryptosystem.xe2x80x9d The Matyas invention focuses on the security practices of the end entity (i.e. the recipient of the certificates), based on an overall security policy for the network. Thus, the Matyas invention only addresses the actions in the communications infrastructure which occur after the issuance of a certificate. It does not address the automated enforcement of policy during the certificate issuance process, nor does it address the role of RAs in the certificate issuance process.
In addition, various PKI implementations may have differing requirements which must be enforced by the CA and RA. For example, the validity period for a certificate in a particular PKI might be one year. However, an entity that implements a high assurance CA that issues certificates in that particular PKI may desire to further restrict the validity period to, for example, the month. The ability to further restrict the validity period might not be a standard feature of the CA or RA in the example PKI.
In order to automate policy enforcement, policy enforcing modules are needed which will allow a customized solution for a particular PKI. Without such a module, the varying requirements between different PKIs would make the implementation of a CA or RA large and cumbersome. In addition, CA or RA operators would be unable to further modify or tailor policy requirements to their specific needs. Furthermore, implementers of new PKIs might decide to sacrifice security or to weaken other requirements in order to conform with existing features in a CA or RA. A policy enforcing module would overcome these problems.
During deployment of a policy enforcement system, a policy implementer can configure the policy elements to be enforced by a communications infrastructure component via a policy enforcing module. In particular, the Programmable Policy Module (PPM), one type of policy enforcing module available in the S2CA, a CA product made by SPYRUS, Inc. of Santa Clara, Calif., can provide the ability to configure and enforce policy. The PPM assists in the enforcement of the policy elements selected in order to meet one or more target policies.
In one embodiment, a PPM can provide a linkage between the policy elements in a certificate policy (CP) identified in the policy extension of the X.509 certificate of a PKI component, and a system that enforces that policy during operations involving a certificate. A PPM can execute at a PKI component and can enforce the policy elements in a CP which defines policies governing the entities within a PKI.
It is an object of the present invention to provide a method for linking policy data and the execution of a module that enforces specific policy elements. It is a further object of this invention to allow an integrator to customize the specific policy elements in order to provide a high assurance product to enforce specific policies. Another object of this invention is to provide a system which will allow enforcement of core policy requirements by a generic PKI component, while also allowing enterprise specific policy requirements to be enforced by a policy enforcing module.